Cancel stale On PR runs via concurrency group#775
Merged
Conversation
Adds a concurrency group on the On PR workflow with cancel-in-progress: true. Context: the upstream-release-docs workflow pushes multiple commits in quick succession to a Renovate PR branch — the skill's content commit, then a prettier/eslint autofix commit that cleans any formatting drift the skill introduced. Without concurrency, the On PR workflow runs fully on each intermediate commit and the first one (pre-autofix) can fail lint. The failure lingers in the check history even though the final commit passes. With cancel-in-progress, when the autofix commit lands, the stale On PR run on the skill commit is cancelled. Only the final run determines the check status. Matches standard GitHub Actions practice for PR CI. Concurrency group is keyed on pull_request.number so PRs can't cancel each other's runs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
There was a problem hiding this comment.
Pull request overview
Adds workflow-level concurrency to the On PR GitHub Actions workflow so that when multiple commits land in quick succession on the same PR, older in-flight runs are automatically cancelled and only the latest run’s result is reflected in checks.
Changes:
- Introduces a
concurrencygroup keyed bypull_request.numberfor theOn PRworkflow. - Enables
cancel-in-progressto stop stale CI runs when a newer commit triggers a new run. - Documents the rationale inline in the workflow file.
danbarr
approved these changes
Apr 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
On PR #759, after the upstream-release-docs workflow pushed the skill's generation commit, the `On PR` workflow's Lint and format checks job ran against that still-unformatted commit and reported FAILURE. A later step in the same upstream workflow ran prettier/eslint and pushed a fixup commit, triggering a new `On PR` run that succeeded — but the earlier FAILURE lingered in the check history.
The race is unavoidable on our side: `claude-code-action@v1` auto-commits AND auto-pushes with no configurable way to disable either, so intermediate commits always hit the branch before the autofix step can run.
Fix
Add a concurrency group on `on-pr.yaml`:
```yaml
concurrency:
group: on-pr-${{ github.event.pull_request.number }}
cancel-in-progress: true
```
When the autofix commit lands, the in-flight `On PR` run on the skill commit cancels. Only the final run determines check status. This is standard GitHub Actions practice for PR CI — rapid-fire commits (humans pushing fixups, or our skill pipeline) don't tie up runner minutes on stale results.
Keyed on `pull_request.number` so PRs can't cancel each other's runs.
Doesn't affect